Referring to FIG. 9, the Universal Mobile Telecommunications System (UMTS) packet network architecture includes the major architectural elements of user equipment (UE), UMTS Terrestrial Radio Access Network (UTRAN), and core network (CN). The UE is interfaced to the UTRAN over a radio (Uu) interface, while the UTRAN interfaces to the core network over an Iu interface. FIG. 10 shows some further details of the overall architecture. The Iu protocol includes a user plane (UP) protocol as shown in FIG. 11. A user plane protocol implements the actual radio access bearer service, i.e., carrying user data through the access stratum. Another way of looking at the user plane protocol is shown in FIG. 12. It is distinguished from the control plane protocol of FIG. 13 that controls the radio access bearers and the connection between the UE and the network from different aspects (including requesting the service, controlling different transmission resources, handover and streamlining, transfer of NAS messages, etc). See 3G TS 25.401 §5.
An objective of having the Iu User Plane (UP) protocol is to remain independent of the CN domain (Circuit-Switched or Packet-Switched) and to have limited or no dependency with the Transport Network Layer (TNL). Meeting this objective provides the flexibility to evolve services regardless of the CN domain and to migrate services across CN domains. The Iu UP protocol is therefore defined with modes of operation that can be activated on a Radio Access Bearer (RAB) basis, rather than on a CN domain basis or (tele)service basis. The Iu UP mode of operation determines if and which set of features shall be provided to meet, e.g., the RAB QoS requirements.
The modes of operation of the UP protocol are defined (3G TS 24.415 §4.2.1) as (1) Transparent Mode (TrM), and (2) Support Mode for predefined SDU size (SMpSDU). Determination of the Iu UP protocol instance mode of operation is a CN decision taken at RAB establishment based on, e.g., the RAB characteristics. It is signaled to the Radio Network Layer (RNL) control plane at RAB assignment and relocation for each RAB. It is internally indicated to the Iu UP protocol layer at user plane establishment. The choice of a mode is bound to the nature of the associated RAB and cannot be changed unless the RAB is changed.
The transparent mode is intended for those RABs that do not require any particular feature from the Iu UP protocol other than transfer of user data. The Iu UP protocol layer in transparent mode over the Iu interface is illustrated in FIG. 2 of 3G TSG RAN: “UTRAN Iu Interface User Plane Protocols (Release 1999)”, TS 25.415 v 3.2.0 (2000-03). In this mode, the Iu UP protocol instance does not perform any Iu UP protocol information exchange with its peer over the Iu interface: no Iu frame is sent. The Iu UP protocol layer is crossed through by PDUs being exchanged between upper layers and transport network layer. Operation of the Iu UP in transparent mode is further discussed in Section 5 of 3G TSG RAN 25.415 v 3.2.0 (2000-03).
For transport of the user data, it is known from 3G TSG RAN: “Services Provided by the Physical Layer” 3G TS 25.302 v 3.3.0 (2000-01) that a Transmission Time Interval (TTI) is defined as the inter-arrival time of Transport Block Sets (TBSs), and is equal to the periodicity at which a TBS is transferred by the physical layer on the radio interface. It is always a multiple of the minimum interleaving period (e.g., 10 ms, the length of one Radio Frame). The MAC delivers one TBS to the physical layer every TTI. Furthermore, plural TBSs may be exchanged at certain time instances between MAC and L1 by parallel transport channels existing between a UE and the UTRAN. Each TBS consists of a number of Transport Blocks (although a single Transport Block can be sent in a TTI as well). The TTI, i.e., the time between consecutive deliveries of data between MAC and L1, can vary, for instance 10 ms, 20 ms, 40 ms, 80 ms between the different channels. Moreover, the number of transport blocks and the transport block sizes can also vary, even within a channel. Therefore, the UTRAN is able to operate in this manner, and it would be advantageous to be able to continue to operate in this manner within the UTRAN because of its inherent flexibility, even if the Iu-interface between the UTRAN and the CN may be defined differently. There is, in fact, a conflict between emerging standards that creates a problem in this regard.
The current TSG RAN TS 25.322 RLC (Radio Link Control) protocol specification defines such functions as segmentation and buffering for the Transparent RLC. The use of buffering on the RLC layer is mainly an implementation issue, but segmentation has been defined in such a way that it is to be performed according to a predefined pattern. This pattern defines that all RLC Protocol Data Units (PDUs) carrying one RLC Service Data Unit (SDU) shall be sent in one TTI (i.e., the segments shall all be carried in one TTI) and only one RLC SDU can be segmented in one TTI (see Section 9.2.2.9).
This definition is useful when the size of the SDU is fixed and the TTI on the Iu-interface and in UTRAN are defined to be equal. Consequently, the above-mentioned definition makes Transparent RLC useful basically only for certain CS services in which the SDU size is either equal to the size of a TB (transport block) or it is always modulo 0 of the TB. Therefore the mode used on the Iu-interface should normally be the above-mentioned Support mode for predefined SDU size (SMpSDU), which allows use of a Rate Control procedure to change the size of the SDU within a valid RAB sub Flow Combination (RFC), but not a valid TTI on the Iu-interface. This kind of CS service, which uses the services of the transparent RLC in this form is, e.g., AMR codec speech.
However the current 3GPP TSG CN TR 23.910: “Circuit Switched Data Bearer Services” defines also such CS data services, in which                the payload consists of user data bits only (i.e., no header has been added into the data stream).        use only transparent mode on the Iu-interface (i.e., no control frames have been defined for the Iu User Plane mode and therefore it is not possible to perform Rate Control during the data transmission).        the payload (SDU) size is fixed (i.e., there is an association between the SDU size and the bit rate on the IuBinterface).        always use a 10 ms TTI on the Iu-interface.        the CS data services are defined to support Conversational traffic class in UTRAN.        the CS data services always use the services of the transparent RLC in UTRAN.        
The characteristics listed above justify the use of the transparent RLC in UTRAN, however they are not in line with 3GPP TSG RAN TS 25.322 specifying the RLC Protocol and 3GPP TSG RAN TR 25.926 specifying the UE capability. The current RLC protocol specification (TS 25.322) doesn't restrict the use of any TTIs (defined in 3GPP TSG RAN TS 25.302) during the data transmission from a transparent RLC entity to a peer entity layer through UTRAN. In other words, although only one SDU is allowed to be segmented and transported in one TTI, the periodicity of the TTI is not restricted to 10 ms by the RLC protocol specification.
Thus the contradiction between the UE capability document and the Circuit Switched Data Bearer Services document is the manner in which the TTI is used for Conversational traffic class. The UE capability document 3G TSG RAN: “UE Radio Access Capabilities” (3G TR 25.296) presents the reference RABs at Table 6.1 thereof, which includes a Conversational Reference TTI of 40 ms for 64 kbps. At this time the actual value of the TTI is not important. The more important issue is that the idea to use other than 10 ms in UTRAN has been presented for this traffic class.
So the main problem is how to map data received from the Iu-interface, e.g., every 10 ms, to the valid TTI, when the TTI used in UTRAN (TTIs of various periodicities) is different from the transmission interval used on the Iu interface (10 ms).